Overview of Object-Oriented Programming
Prior to the development of object-oriented programming, a form of programming was developed known as structured programming, which is still used extensively. In this technique, various functions are first defined, and the program then consists of calling such defined functions at appropriate times to effect the overall objective of the application program. Such functions define the methods that are used to operate on the data, but do not define the data itself. Structured programming provided the opportunity of a modularised approach--a significant improvement over "spaghetti code" which was difficult to debug and maintain. Nevertheless, several drawbacks to structured programming remain, such as the "semantic gap" between the concepts and entities in the world being modelled by the program and the concepts in the programming language, the textual nature of the program code, and limitations on reusability of code modules.
Subsequently, a new programming paradigm was developed, referred to as object-oriented programming. In this technique, instead of defining functions, "classes" are defined. The class definitions define the methods which any instance of that class can perform and the attributes (or data) that an instance of that class contains. An object is a member of a class and can actually perform the methods, which are defined in the class definition. An object has values associated with each of the attributes defined by the class. An object has zero or more attributes and it has zero or more methods that can be performed on the object.
The interface to the object is the way in which the attributes can be accessed through the methods. All objects derived from that class share the interface of that class. The implementation of an object is hidden from the application which calls the object. As long as the interface to the object does not change, the implementation may be completely altered without affecting the application.
As a simplistic example of this technique of describing the external "appearance" of an object without the necessity of describing what it "looks like" or "does" inside, and in order to illustrate the significant benefits of such object-oriented programming, one might imagine, by analogy, a common household toaster, which could be modeled by the object-oriented approach. The external "interface" would consist of the knob, which essentially represents a parameter for adjusting the desired lightness or darkness of the toast, the slot into which the bread is inserted, and a lever for effecting the insertion and activating the toaster. The important concept is that the end-user of such an appliance does not need to know the "internals" of the toaster in order to use it, e.g. whether heat is provided by electricity, or by chemical or other means. All the user would have to do is interface properly with these externals.
The beauty of this evolution in programming is that, continuing with the analogy, the designer of the object, which might be a module of programming code modelling a toaster, may focus on improving the internals of the toaster, making it more efficient, for example, without affecting the user's ability to use the object, in as much as the internals are transparent to the user. Thus, more abstractly, object-oriented technology may be seen essentially as providing the advantage of separation of the interface of an object from its implementation. In a software context, the internals of the object may thereby be rewritten and improved without the necessity of rewriting the entire application program, as long as the external "knobs" etc, and their expected behaviour have not changed.
For further general background regarding object technology to facilitate a better understanding of the invention, reference should be made to "Object Oriented Technology--A Manager's Guide", by David A. Taylor, copyright 1990, Servio Corporation.
With the development of object-oriented programming, several "object models" were further refined and developed by various organisations and software companies. These specified the manner in which one was to define objects and their external interfaces, such various object models providing characteristics of encapsulation and inheritance among others. At an appropriately high level, these various object models are very similar. Examples are the System Object Model (SOM), Common Lisp Object System (CLOS), Smalltalk, and C++. In essence, these various object models are simply a body of rules answering the question of what an object is, each offering slightly different answers when examined at lower levels. For example, various object models differ in their language syntax, and in how encapsulation and inheritance work.
As a direct result of these differences, one problem presented by the availability of different object-oriented languages and object models was that interoperability between object programs written in a mixture of such languages could not be achieved. This problem adversely impacted one of the major promises of object technology, namely reusability of code. In an effort to address this problem plaguing the industry, a Common Object Request Broker Architecture (CORBA) was arrived at by committee, which included a standardized Interface Definition Language (IDL). There was in essence an agreement in the industry as to how interfaces of an object would be specified, i.e. a standard for defining object interfaces so that objects defined by one vendor could be utilized by another. See "The Common Object Request Broker:Architecture and Specification", OMG Document Number 91.12.1 Revision 1.1.
Object Request Broker (ORB)
The Object Request Broker (ORB) described in the CORBA architecture is analogous to the Remote Procedure Call (RPC) familiar to those working in the UNIX operating system environments (UNIX is a trademark exclusively licensed through X/Open Co. Ltd).
FIG. 1 shows a client/server environment including an ORB. The ORB is split into two parts, part 50 of which executes in each of the clients using the ORB and part 52 of which executes in each of the servers supporting the ORB. Like an RPC, an ORB is a mechanism which allows client applications 48 working in one address space 53 to communicate with objects 51 in another address space 54. Objects 51 located in the other address space 54, that is not the same address space 53 as that in which the client application 48 is executing, are referred to as "remote" objects. Objects located in the same address space 53 as the client application 48 are referred to as "local" objects. An ORB 50 intercepts a call from a client application 48 in one address space 53, encapsulates it into a network protocol, decodes the call for the target object 51 in another address space 54 and returns the results back to the calling client application 48. This allows a client application 48 working in one address space (local) to communicate with objects 51 in another address space (remote). ORB is an improvement upon the RPC as it is designed to provide the higher level of flexibility and power offered by object oriented programming.
"Object models" have been developed by various organisations and software companies. The object models specify the manner in which objects and their external interfaces are to be defined. One of these object models is System Object Model (SOM) from IBM Corporation. In SOM, all applications using objects run in a single address space in which the objects are also located. A development within SOM is a framework of object classes called Distributed System Object Model (DSOM). In DSOM, applications (running in clients) in one address space may access objects in another address space (such as an address space belonging to a server). These address spaces may be in the same or different systems. In fact, the systems need not be running the same platform. For example, a client application running in an address space on an OS/2 system may access an object that is located in an address space on an AIX/6000 system, or vice versa. Both SOM and DSOM are described in "SOMobjects: A Practical Introduction to SOM and DSOM", published by IBM Corporation, Copyright 1994, Order no. GG24-4357-00.
The aforementioned System Object Model (SOM) is one object model which conforms to CORBA and IDL. Conformance means that SOM objects follow CORBA semantics, and SOM objects are defined in IDL syntax.
The DSOM framework provides object implementations that insulate the client programmer from having to have knowledge of the location or platform type where a target object will be instantiated. The communications facilities used for this inter-process communication are completely hidden from the programmer.
Client-Server Architecture
In a client-server architecture, application programs are divided into distinct tasks that execute as individual components. Each of the components are assigned roles as clients or as servers. A single component may perform the role of a server for some purposes and of a client for other purposes. Each of the components operates independently and assumes certain responsibilities. Those components which are assigned the role of client request services from a server by making method calls on an object in a server process. Those components which are assigned the role of server provide services by receiving these method calls, invoking them on the appropriate object and returning the results to the client. The clients and servers exchange messages using a predefined protocol. Servers can service many clients and clients can draw upon the services of many servers.
Proxy Objects
A proxy object is an object that is a local representative for a remote target object. A proxy object inherits the target object's interface, so that it responds to the same methods. Methods invoked on the proxy object are not executed locally, but are forwarded to the real target object for execution. A program running in a client always has a local proxy object, in the client, for each remote object, in a server, on which it operates. The proxy object contains, within it, a pointer to the memory location in the server where the target object is located. It does not contain the name of the target object. The proxy object is created by the DSOM run-time environment whenever a request is made to a remote server to invoke a method on a remote object.
DSOM Environment
Client processes make method calls on objects in a server process. These method calls may, for example, get the value associated with an attribute (read) or set the value associated with an attribute (write). The server process will receive these method calls, invoke them on the appropriate object and return the results to the client. FIG. 2 provides a very high-level view of some of the components of a DSOM environment. The client address space 53 includes an object called the DSOM Object Manager 303. This object assists the client application (48 in FIG. 1) with locating servers 54 by returning a pointer to a proxy object 305 (described below) for the server object 313. The client then invokes methods on the server object 313 (via its proxy object 305) in order to create instances of objects 51 of predefined classes on that server 54, to gain access to objects 51 that already exist on that server or to destroy objects 51 on that server 54 when they are no longer needed.
The client application (48 in FIG. 1) makes calls to the server proxy object 305 to find out the location of an object 51 on which it wishes to make a method call. The server proxy object 305 calls the server object 313 to determine the memory location of the target object 51 in the server. The server object obtains this information from a name server 317, whose function is to provide a memory location given an object name. Its function will be familiar to those working in the UNIX operating system environment. The server object 313 provides the memory location of the target object 51 to the server proxy object 305. A proxy object 49 for the target object 51 is then created in the client address space 53. The local client application can then make method calls on the local proxy object 49 as if it were the remote target object 51. DSOM will pass the method call to the server address space 54 where the method call is invoked on the target object 51 and the results will be returned to the local client application.
On any system that will act as a server, or as a client, or as both, a separate daemon process 341 called "somdd" must be active. This process is instrumental in initializing server processes, providing services that must be available at all times and in creating a binding between the client process and the server process. The term "daemon process" and its function will be familiar to those working in the UNIX operating system environment. It plays no further part in the present invention.
There are two additional facilities that are required in a DSOM environment. These are the Interface Repository 321 and the Implementation Repository 331.
The Interface Repository 321 is a database for storing object interface definitions. Class interface definitions (a method's parameters and return value) are registered with the Interface Repository. The Interface Repository plays no part in the present invention. Server implementations and the classes they support are registered in the Implementation Repository. That is, servers and classes and the attributes necessary for DSOM to find and activate an object server (such as the server program name, hostname of the machine where the server is located, and so on) are registered in the Implementation Repository.
Persistence
A persistent object is one in which the attributes associated with the object are stored in non-volatile storage and are available even after the process that created it has terminated. An object which is not persistent does not have the attributes associated with the object stored in non-volatile storage and the attributes of the object are not available after the process that created it has terminated. If a server crashes, then non-persistent objects will not be restored, while persistent objects will be restored, if the server is a recoverable server so that it restarts after a malfunction occurs.
Server malfunction
Referring to FIG. 2, if the server 54 malfunctions, the reference in the proxy object 49 located in the client address space 53 to a target object 51 located in the server address space 54 will no longer be valid. The server 54 will reload the object into memory so as to make it available to the client application (48 in FIG. 1). The server 54 may reload the object 51 into memory at a different location to where it was prior to the malfunction. If the object 51 had been loaded specifically at the request of the client application (48 in FIG. 1), that is, it is not a persistent object, then the server 54 may not even reload the object 51 into memory at all. In both of these situations, the reference contained within the proxy object 49 to the target object 51 in the server 54 will no longer be valid. Use of the proxy object 49 will result in an error condition indicating that the object referenced is a bad object or similar. In some Object Request Broker implementations this can have serious effects, such as corruption of memory in the server or even malfunction of the server requiring a further restart of the server.
When the client application 48 receives an error condition indicating that one of more of its proxy objects 49 have become invalid, it will need to perform one of the following steps:
A. If the target object 51 was not persistent, the client application 48 will need to create a new target object 51 in the server 54. The client application 48 calls a server proxy object 305 to request that a new target object 51 be created giving the class of object to be created. The server proxy object 305 calls the server object 313 to determine the memory location of the target object 51 in the server 54. The server object 313 provides the memory location of the target object 51 to the server proxy object 305. A proxy object 49 for the target object 51 is then created in the client address space 53. The proxy object 49 includes a reference to the location in memory in the server 54 where the target object 51 can be found. PA0 B. If the target object was persistent, then the client application 48 will need to create a new proxy object 49 including a reference to the location in memory in the server 54 where the target object 51 can be found. PA0 1. It needs to destroy the old proxy objects 49 which now contain references to memory locations in the server 54 which were valid references to target objects 51 before the server 54 malfunctioned, but which are now invalid. PA0 2. It needs to create new proxy objects 49 corresponding to each of the old proxy objects. These new proxy objects 49 correspond to the old ones, except that the references they contain to target objects 51 in the server 54 are valid references, obtained since the server 54 restarted after the malfunction. PA0 3. All of the pointers in the client application to the proxy objects 49 located in the client address space 53, which were destroyed at step 1, now need to be updated to point to the new corresponding proxy objects 49 created at step 2. This step requires knowledge specific to the application that needs to have its pointers updated.
If a server 54 has malfunctioned, then it is likely that all references from proxy objects 49 located in the client address space 53 to all of the target objects 51 located in that server 54 will need to be refreshed by carrying out the steps listed above. This is a non-trivial exercise for a typical client application 48. The client application 48 has pointers to proxy objects 49 located at various places throughout its address space and needs to perform the following tasks:
If a server malfunctions, the references in the proxy object located in the client to the target objects located in the server will no longer be valid. The Object Request Broker will generate a TIMEOUT error when the client tries to use the invalid reference, since the remote server no longer exists.
Preventing Invalid Proxy Object Usage
Every server implemented using the DSOM framework has a server object, to which all incoming messages are directed. This object dispatches the messages to their true destination, which will be another object in the same DSOM server. A method of preventing invalid proxy object usage is for the DSOM server to do some basic checking of a timestamp associated with the proxy object and with a timestamp associated with the DSOM server itself and return an error condition if the timestamp associated with the DSOM server is later than that associated with the proxy object. Similar checks may be performed in systems utilising other Object Request Brokers.
These checks detect that an error has occurred and that the reference contained within a proxy object is invalid, but they provide no way in which the error can be corrected. The references may be corrected using application specific knowledge and code to correct the references in the proxy objects located in the client applications. "Object replacement using dynamic proxy updates", S Menon, R J LeBlanc Jr, Dist. Syst. Engng 1 (1994) pp.271-279, discloses an object replacement scheme in which, on receiving an error indicating that a proxy object reference to a target object is invalid, the proxy object requests an updated reference from a Name Server. Low level events are used to detect errors and update proxy objects. The object replacement scheme is specifically for use with the Clouds distributed operating system. The scheme described does not work with other operating systems or with Object Request Brokers in general.